The Internet comprises a large number of computers and computer networks that are interconnected through communication channels. Because it facilitates electronic communications between vendors and purchasers, the Internet is increasingly being used to conduct “electronic commerce.” Electronic commerce refers generally to commercial transactions that are at least partially conducted using the computer systems of the parties to the transactions. For example, a purchaser can use a personal computer to connect via the Internet to a vendor's computer. The purchaser can then interact with the vendor's computer to conduct the transaction. Although many of the commercial transactions that are performed today could be performed via electronic commerce, the acceptance and widespread use of electronic commerce depends, in large part, upon the ease-of-use of conducting such electronic commerce. If electronic commerce can be easily conducted, more vendors and purchasers will choose to engage in electronic commerce.
One of the fundamental aspects of electronic commerce is the creation and maintenance of a useful web site through which vendors and buyers can carry out transactions. Typically, an e-commerce site allows vendors to display product information (e.g., product descriptions, price information, product images) and allows customers to browse for products and place and confirm orders. Initially creating this type of site can be complicated, costly, and time-consuming. As with the display of physical products in a store, it is important that product information on a web site be well organized and attractively displayed so customers can easily find what they are looking for. Likewise, it is desirable to provide a system for obtaining purchase information from customers in a simple and efficient way. Once the site is initially created, it is important to update the site as new products are offered for sale and old products are sold out or discontinued. Special sales or promotions may also call for changes to the site, as may reorganizations of the site to further optimize its usability.
The version of a web site that is currently being presented to customers is termed the “live” version of that web site. When a merchant's designers commence to make changes that will update the merchant's web site, it is desirable to continue to display the unchanged live version of the web site to customers until the designers' changes are completed, approved, and otherwise ready for release. At that point, the changed version of the web site becomes the new live version, and as such is presented to customers. A group of changes that is applied together to a web site in this manner is termed a “release.”
One way of continuing to present the live version of the web site while simultaneously making changes to the web site that will be reflected in a future version is to make a copy of all of the data that comprises the live web site, including the scripted templates that represent each web page in the web site, all of the other digital content that is incorporated in pages of the web site, and various other data. The changes are then made to the copy. This approach has the advantage that the copy can be used to preview the changed version of the web site. In the case of large web sites, however, this approach can have a substantial impact on the data storage requirements for operating the web site.
In cases where the designers need to be able to simultaneously work on changes for multiple future releases of the web site, additional disadvantages appear for this approach. First, the need to have a separate full copy of the web site for each future release being worked on further increases data storage requirements. Further, when using this approach, a change must be applied to every release scheduled later than every release in which it is to be effective. For example, if at a particular point in time five different future releases exist, and a change is to be made to the second of these five, the change must be applied not only to the second, but also to the third, fourth, and fifth.
An alternative approach is make use of a differential rendering approach, in which there is only a single copy of the web site, but the pages of the web site can either be rendered in their live version, or rendered in accordance with a future release. This may be accomplished by, for each page of the web site that is changed, introducing tests into the script that is executed to transform the template representing the page into the page. These tests determine whether the page is to be rendered in its live version for presentation to customers, or in accordance with a future release for presentation to developers previewing that release. The script incorporates the content that is appropriate for the determined version based on the test results.
For example, a developer that wanted to change a particular page that, in the live version of the web site, includes a picture of an orange leaf to instead include a picture of a snowflake in a future release, would modify the script in the template for that page. In the script, the developer would change an unconditional command to incorporate the orange leaf picture to a conditional structure that (1) determines the version of the page being rendered, (2) if the version of the page being rendered is the live version, incorporates the orange leaf picture, and (3) if the version of the page being rendered is the future release version, incorporates the snowflake picture. In order to make the future release of the web site live, the scripts must again be modified to contain unconditional commands to incorporate the content as changed by the release, e.g., to replace the above-described conditional structure with an unconditional command to incorporate the snowflake picture.
This approach also has significant disadvantages. First, each changed page must be revised in the manner described, often manually. This requires substantial amounts of manual effort. Further, this manual process makes it difficult to use automated tools to specify changes for a release. Also, each time a page is changed in this manner, it is possible for the changes to introduce error. Additionally, introducing additional code paths by adding conditional structures makes the templates more complex to test. Furthermore, where more than one future release exists, the conditional structures become more complex, and correspondingly more difficult to test.
In view of the foregoing, those skilled in the art will appreciate that an improved mechanism for managing future releases would have significant utility.
In some cases, it may be desirable to operate a single web site on behalf of multiple merchants. Such a multiple-merchant web site can in some cases provide economies of scale, as well as marketing synergies that cause a customer to make more purchases on the combined web site than that customer would have otherwise made on individual single-merchant web sites.
Multiple-merchant web sites can raise difficult security issues, however. If developers for each merchant are granted authorization to change any page on the web site, one merchant's developer can carelessly or maliciously change a page of another merchant. If, on the other hand, the ability to change the pages of all of the merchants is restricted to employees of an organization that is responsible for operating the web site as a whole, an extra layer of delegation is imposed on the designers of each merchant—who have to communicate their changes to employees of the organization—and the organization incurs the extra cost of allocating designers to this task.
For these reasons, those skilled in the art will appreciate that an improved mechanism for managing modification permissions in a multiple-merchant web site would have significant utility.